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Section  1. 
Summary 


A  Technology  Readiness  Assessment  (TRA)  is  a  systematic,  metrics-based 
process  that  assesses  the  maturity  of,  and  the  risk  associated  with,  critical  technologies  to 
be  used  in  Major  Defense  Acquisition  Programs  (MDAPs).  It  is  conducted  by  the  Pro¬ 
gram  Manager  (PM)  with  the  assistance  of  an  independent  team  of  subject  matter  experts 
(SMEs).  It  is  provided  to  the  Assistant  Secretary  of  Defense  for  Research  and 
Engineering  (ASD(R&E))  and  will  provide  part  of  the  bases  upon  which  he  advises  the 
Milestone  Decision  Authority  (MDA)  at  Milestone  (MS)  B  or  at  other  events  designated 
by  the  MDA  to  assist  in  the  detennination  of  whether  the  technologies  of  the  program 
have  acceptable  levels  of  risk — based  in  part  on  the  degree  to  which  they  have  been 
demonstrated  (including  demonstration  in  a  relevant  environment) — and  to  support  risk- 
mitigation  plans  prepared  by  the  PM.  The  plan  for  conducting  a  TRA  is  provided  to  the 
ASD(R&E)  by  the  PM  upon  approval  by  the  Component  Acquisition  Executive  (CAE). 

A  TRA  is  required  by  Department  of  Defense  Instruction  (DoDI)  5000.02  for 
MDAPs  at  MS  B  (or  at  a  subsequent  Milestone  if  there  is  no  MS  B).  It  is  also  conducted 
whenever  otherwise  required  by  the  MDA.  It  is  required  for  space  systems  by  Under 
Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics  (USD(AT&L)) 
memorandum  Transition  of  the  Defense  Space  Acquisition  Board  (DSAB)  Into  the 
Defense  Acquisition  Board,  dated  March  23,  2009.  The  TRA  final  report  for  MDAPs 
must  be  submitted  to  ASD(R&E)  for  review  to  support  the  requirement  that  ASD(R&E) 
provide  an  independent  assessment  to  the  MDA. 

A  TRA  focuses  on  the  program’s  “critical”  technologies  (i.e.,  those  that  may  pose 
major  technological  risk  during  development,  particularly  during  the  Engineering  and 
Manufacturing  Development  (EMD)  phase  of  acquisition).  Technology  Readiness  Levels 
(TRLs)  can  serve  as  a  helpful  knowledge-based  standard  and  shorthand  for  evaluating 
technology  maturity,  but  they  must  be  supplemented  with  expert  professional  judgment. 

To  reduce  the  risk  associated  with  entering  EMD,  DoDI  5000.02  requires 
Requests  for  Proposals  (RFPs)  to  incorporate  language  that  prevents  the  award  of  an 
EMD  contract  if  it  includes  technologies  that  have  not  been  demonstrated  adequately. 
Adequate  demonstration  in  a  relevant  environment  (TRL  6)  is  one  benchmark  that  is 
evaluated,  but  it  is  not  the  only  consideration,  nor  necessarily  dispositive.  As  such,  a 
generic  TRA  not  based  on  the  planned  specific  technical  solution  is  insufficient.  Since 
the  TRA  must  be  based  on  the  technologies  of  the  program  that  entail  some  element  of 
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risk,  TRAs  may  have  to  be  performed  on  all  the  competitors’  proposals  in  a  source 
selection. 

In  accordance  with  a  USD(AT&L)  memo  titled  Better  Buying  Power:  Guidance 
for  Obtaining  Greater  Efficiency  and  Productivity  in  Defense  Spending,  dated  Septem¬ 
ber  14,  2010,  the  TRAs  described  in  this  Guidance  replace  the  former  TRAs  described  in 
the  Technology  Readiness  Assessment  Desk  Book,  dated  July  2009. 1  TRAs  that  must  be 
submitted  to  ASD(R&E)  are  required  only  for  MDAPs  that  require  certification  under 
10  U.S.C.  §2 3 66b  or  other  provisions  of  law,  or  when  otherwise  directed  by  the  MDA. 
Generally,  TRAs  are  not  required  for  MDAPs  at  MS  C.  Independent  of  the  elimination  of 
the  formal  requirement  to  conduct  a  TRA  for  a  Major  Automated  Information  System 
(MAIS),  MS  C,  and  Acquisition  Category  (ACAT)  II-IV  programs,  all  PMs  and  their 
chains  of  command  retain  complete  responsibility  for  assessing,  managing,  and  miti¬ 
gating  acquisition  program  technology  risk.  MDAs  for  non- ACAT  I  programs  should 
consider  requiring  TRAs  for  those  programs  when  technological  risk  is  present. 


1  See  https://acc.dau.mil/CommunityBrowser.aspx7idM8545. 
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Section  2. 

Initiating  and  Conducting  a  TRA 


2.1  Key  Players 

Key  players  in  the  TRA  process  are  as  follows: 

•  The  Milestone  Decision  Authority  (MDA)/Defense  Acquisition  Executive 

(DAE), 

•  The  Component  Acquisition  Executive  (CAE)/Program  Executive  Officer 

(PEO)  and  Science  and  Technology  (S&T)  Executive, 

•  The  Program  Manager  (PM), 

•  The  Assistant  Secretary  of  Defense  for  Research  and  Engineering 

(ASD(R&E)),  and 

•  The  team  of  independent  subject  matter  experts  (SMEs). 

2.2  Roles  and  Responsibilities 

Key  player  roles  and  responsibilities  are  as  follows: 

•  The  MDA 

-  Determines  whether  to  approve  the  Milestone  decision  or  to  defer  until 
technology  matures. 

-  Determines  whether  or  not  the  technologies  of  the  program  can  be 
certified  under  10  U.S.C.  §  2366b  based  on  independent  review  and 
assessment  by  ASD(R&E),  which  review  and  assessment  are  informed, 
in  part,  by  the  program  TRA. 

-  In  case  of  technologies  not  demonstrated  in  a  relevant  environment, 
detennines  whether  the  PM’s  proposed  risk-mitigation  plans  are 
adequate  and,  in  turn,  detennines  whether  to  issue  a  waiver  under  10 
U.S.C.  §  2366b. 

-  With  the  user,  determines  if  risk  can  be  reduced  to  an  acceptable  level  by 
relaxing  program  requirements. 
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•  The  CAE/PEO  and  S&T  Executive 

-  Approves  the  PM’s  TRA  plan  and  assigns  additional  participants  as 
desired. 

-  Reviews  and  approves  the  list  of  critical  technologies  that  pose  potential 
risk  to  program  success  and  that  are  to  be  assessed  in  the  TRA. 

-  Reviews  and  approves  the  TRA  final  report  and  cover  memorandum  and 
includes  any  additional  material  desired. 

-  Transmits  the  completed  TRA  to  ASD(R&E). 

-  Raises  any  issues  that  cannot  be  resolved  with  the  ASD(R&E)  to  the 
MDA. 

The  CAE  may  choose  to  make  the  Service  S&T  Executive  a  key  participant  in  the 
TRA  process.  For  example,  the  CAE  may  direct  the  S&T  Executive  to  take  responsibility 
for  TRA  management  and  execution.  The  CAE  may  assign  the  S&T  Executive  as  a 
reviewer/signatory  on  MDAP  Technology  Development  Strategies  (TDSs)  to  support 
identification  and  management  of  critical  technologies  leading  up  to  MS  B. 

•  The  PM 

-  Assesses  the  technological  risk  in  his/her  program. 

-  Plans  and  ensures  funding  of  the  program’s  risk-reduction  activities  to 
ensure  that  technologies  reach  the  appropriate  maturity  levels  prior  to 
being  incorporated  into  the  program  baseline  design.  A  key  benchmark 
is  that  the  technologies  of  the  program  be  demonstrated  in  a  relevant 
environment  at  MS  B  or  at  a  subsequent  Milestone  if  there  is  no  MS  B 
for  this  program.  If  this  benchmark  is  not  achieved,  a  waiver  by  the 
MDA  is  possible,  but  this  waiver  must  be  based  on  acceptable  means  of 
risk  mitigation,  such  as  inclusion  of  an  alternative  more  mature  technol¬ 
ogy  as  a  funded  option. 

-  Prepares  a  plan  for  conduct  of  the  TRA.  Receives  approval  of  the  plan 
through  CAE  and  PEO  and  provides  the  plan  to  ASD(R&E)  upon 
approval  by  the  CAE. 

-  Funds  the  TRA  and  ensures  that  it  is  properly  carried  out. 

-  Prepares  a  draft  TRA  schedule  and  incorporates  the  approved  version  in 
the  program’s  Integrated  Master  Plan  (IMP)  and  Integrated  Master 
Schedule  (IMS).  A  draft  TRA  should  be  completed  prior  to  the  MDA 
Defense  Acquisition  Board  (DAB)  Pre-MS  B  Program  Review  that 
precedes  EMD  RFP  release  and  MS  B.  After  Preliminary  Design 
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Review  (PDR)  and  prior  to  MS  B  or  another  certification  decision  event, 
the  TRA  will  be  updated  as  needed  based  on  the  PDR  and  source- 
selection  results  to  ensure  that  knowledge  obtained  at  PDR  and  in  the 
proposals  is  available  to  inform  the  ASD(R&E). 

-  In  consultation  with  ASD(R&E)  and  with  PEO  and  CAE  approval, 
identifies  the  subject  matter  expertise  needed  to  perform  the  TRA. 

-  Assigns  members  of  the  SME  team  and  informs  the  CAE,  PEO, 
ASD(R&E),  and  S&T  Executive  of  the  final  membership. 

-  Familiarizes  the  SME  team  with  the  program,  the  perfonnance  and 
technical  requirements,  and  the  designs  under  consideration. 

-  Identifies  possible  critical  technologies  for  consideration  by  the  SME 
team. 

-  Provides  evidence  of  technology  demonstration  in  relevant  environments 
to  the  SME  team  for  assessment,  including  contractor  data  as  needed. 

-  Provides  proposed  risk-mitigation  plans  to  address  remaining  technol¬ 
ogical  risk  associated  with  critical  technologies  to  the  SME  team,  inde¬ 
pendent  of  levels  of  demonstration. 

-  Provides  technical  expertise  to  the  SME  team  as  needed. 

-  Prepares  the  TRA  report  that  will  include  findings,  conclusions,  and 
other  pertinent  material  prepared  by  the  SMEs. 

-  Prepares  the  TRA  report  cover  memorandum,  which  may  include 
additional  technical  information  deemed  appropriate  to  support  or 
disagree  with  SME  team  findings. 

-  Sends  the  completed  TRA,  with  SME  team  comments  unaltered,  through 
the  PEO  to  the  CAE  for  review  and  transmittal  to  ASD(R&E),  together 
with  any  additional  information  the  CAE  chooses  to  provide. 

-  Detennines  whether  a  waiver  to  the  §  2366b  certification  requirement 
may  be  appropriate,  and  if  so,  requests  PEO  and  CAE  approval  to 
request  such  a  waiver. 

•  The  ASD(R&E) 

-  Reviews  the  TRA  plan  provided  by  the  PM  and  provides  comments 
regarding  TRA  execution  strategy  as  appropriate. 


2-3 


-  In  conjunction  with  the  PM  and  SME  team,  reviews  the  PM-provided 
list  of  critical  technologies  to  assess  and  recommends  additions  or 
deletions. 

-  Based  on  the  TRA  final  report,  inter  alia,  provides  the  MDA  an 
independent  assessment  and  review  concerning  whether  the  technology 
in  the  program  has  been  demonstrated  in  a  relevant  environment. 

-  If  a  §  2366b  waiver  has  been  requested,  provides  a  recommendation  to 
the  MDA,  with  supporting  rationale,  as  to  whether  a  waiver  should  be 
granted. 

-  Recommends  technology  maturity  language  for  an  Acquisition  Decision 
Memorandum  (ADM),  noting,  in  particular,  conditions  under  which  new 
technology  can  be  inserted  into  the  program. 

•  The  SME  Team 

-  Works  closely  with  the  PM  throughout  the  TRA  process. 

-  Reviews  the  performance,  technical  requirements,  and  designs  being 
considered  for  inclusion  in  the  program. 

-  In  conjunction  with  the  PM  and  ASD(R&E),  reviews  the  PM-provided 
list  of  critical  technologies  to  assess  and  recommends  additions  or 
deletions. 

—  The  SME  team  should  make  recommendations  to  the  PM  (with 
associated  rationale)  on  the  candidate  technologies  that  should  be 
assessed  in  the  TRA. 

-  Assesses  whether  adequate  risk  reduction  to  enter  EMD  (or  other 
contemplated  acquisition  phase)  has  been  achieved  for  all  technologies 
under  consideration,  including,  specifically,  demonstration  in  a  relevant 
environment. 

—  The  assessment  should  be  based  on  objective  evidence  gathered 
during  events,  such  as  tests,  demonstrations,  pilots,  or  physics- 
based  simulations.  Based  on  the  requirements,  identified  capabili¬ 
ties,  system  architecture,  software  architecture,  concept  of  opera¬ 
tions  (CONOPS),  and/or  the  concept  of  employment,  the  SME 
team  will  evaluate  whether  perfonnance  in  relevant  environments 
and  technology  maturity  have  been  demonstrated  by  the  objective 
evidence. 
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—  If  demonstration  in  a  relevant  environment  has  not  been  achieved, 
the  SMEs  will  review  the  risk-mitigation  steps  intended  by  the 
PM  and  make  a  determination  as  to  their  sufficiency  to  reduce 
risk  to  an  acceptable  level. 

—  TRLs  will  be  used  as  a  knowledge-based  standard  or  benchmark 
but  should  not  substitute  for  professional  judgment  tailored  to  the 
specific  circumstances  of  the  program. 

-  Prepares  the  SME  comments  in  the  TRA  report  including  (1)  the  SME 
team  credentials  and  (2)  SME  team  findings,  conclusions,  and 
supporting  evidence. 

2.3  Process  for  Conducting  a  TRA 

2.3.1  Establish  a  TRA  Plan  and  Schedule 

The  TRA  planning  process  begins  when  the  PM  establishes  a  plan  for  conducting 
the  TRA,  typically  after  MS  A.  After  the  TRA  plan  is  approved  by  the  PEO  and  CAE,  it 
is  provided  to  ASD(R&E)  by  the  PM.  The  TRA  plan  should  include  a  schedule  that 
aligns  with  the  Acquisition  Strategy  (AS),  and  it  should  be  incorporated  into  the 
program’s  IMS.  When  a  pre-MS  B  DAB  Program  Review  is  conducted  prior  to  the 
release  of  the  EMD  RFP,  a  draft  TRA  will  be  reviewed  and  approved  by  the  PEO  and 
CAE  and  provided  to  the  ASD(R&E)  30  days  before  the  pre-MS  B  DAB  Program 
Review.  The  TRA  should  be  finalized  after  PDR  and  at  least  30  days  before  MS  B. 

2.3.2  Form  a  SME  Team 

Once  a  TRA  schedule  has  been  established,  a  team  of  SMEs  should  be  formed. 
Subject  matter  expertise  and  independence  from  the  program  are  the  two  principal 
qualifications  for  SME  team  membership.  Members  should  be  experts  who  have 
demonstrated,  current  experience  in  the  relevant  fields.  It  is  the  PM’s  responsibility  to 
guide  SME  team  members  on  their  role  in  the  TRA  process,  as  provided  for  in  the  TRA 
plan.  The  PM  should  include  an  overview  of  the  system,  an  overview  of  the  TRA 
process,  criteria  for  identifying  critical  technologies,  and  examples  and  instructions  for 
detennining  whether  technologies  have  been  demonstrated  in  a  relevant  environment. 

The  PM  should  exploit  planned  demonstration  events  and  tests  to  provide  the  data  needed 
by  the  SME  team.  SME  team  members  might  be  required  to  sign  non-disclosure  agree¬ 
ments  and  declare  that  they  have  no  conflicts  of  interest. 

2.3.3  Identify  Technologies  To  Be  Assessed 

The  fundamental  purposes  of  the  TRA  are  (1)  to  provide  the  PM  with  a 
comprehensive  assessment  of  technical  risk,  and  (2)  to  support  the  ASD(R&E)’s 
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independent  assessment  of  the  risk  associated  with  the  technologies  incorporated  in  the 
program — including  whether  the  technologies  of  the  program  have  been  demonstrated  in 
a  relevant  environment — so  that  the  MDA  is  informed  as  to  whether  certification  under 
10  U.S.C.  §2 3 66b  can  be  accomplished,  whether  a  waiver  is  appropriate,  and  whether 
risk-mitigation  plans  are  adequate.  Thus,  it  is  important  to  identify  all  appropriate 
technologies  that  bear  on  that  determination.  These  technologies  should  be  identified  in 
the  context  of  the  program’s  systems  engineering  process,  based  on  a  comprehensive 
review  of  the  most  current  system  performance  and  technical  requirements  and  design 
and  the  program’s  established  technical  work  breakdown  structure  (WBS). 

Technology  risk  identification  should  start  well  before  the  fonnal  TRA  process.  In 
fact,  potential  critical  technology  identification  begins  during  the  Materiel  Solution 
Analysis  (MSA)  phase,  which  precedes  MS  A.  An  early  evaluation  of  technology 
maturity,  conducted  shortly  after  MS  A,  may  be  helpful  to  refine  further  the  potential 
critical  technologies  to  be  assessed.  It  may  be  appropriate  to  include  high-leverage  and/or 
high-impact  manufacturing  technologies  and  life-cycle-related  technologies  if  there  are 
questions  of  maturity  and  risk  associated  with  those  technologies. 

The  PM  should  prepare  an  initial  list  of  potential  technologies  to  be  assessed. 
When  competing  designs  exist,  the  PM  should  identify  possible  technologies  separately 
for  each  design.  The  PM  should  make  key  technical  people  available  to  the  SME  team  to 
clarify  information  about  the  program. 

The  SME  team  should  recommend  changes  to  the  list  of  critical  technologies  to 
assess  to  the  PM.  Inputs  to  this  process  include  the  list  of  technologies  developed  by  the 
PM  and  specific  technical  planning  perfonned  by  existing  or  previous  contractors  or 
government  agencies.  The  SME  team  should  be  given  full  access  to  these  data. 

2.3.4  Collect  Evidence  of  Maturity 

Appropriate  data  and  infonnation  are  needed  to  assess  whether  the  technologies 
of  the  program  have  been  demonstrated  in  a  relevant  environment.  The  process  of  col¬ 
lecting  and  organizing  the  material  for  each  technology  should  begin  as  early  as  possible. 
The  PM  should  compile  component  or  subsystem  test  descriptions,  environments,  and 
results  in  the  context  of  the  system’s  functional  needs  as  needed  to  conduct  his/her  own 
assessment  of  technology  maturity  and  as  needed  by  the  SME  team  to  complete  its  work. 
Any  other  analyses  and  information  necessary  to  assess  and  rationalize  the  maturity  of 
the  technologies  should  also  be  included. 

2.3.5  Assess  Technology  Maturity 
2.3.5. 1  SME  Team  Assessment 
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The  PM  must  make  key  data,  test  results,  and  technical  people  available  to  the 
SME  team  to  clarify  infonnation  about  the  program.  The  SME  team  should  assess  critical 
technologies  to  determine  whether  these  technologies  have  been  demonstrated  in  a 
relevant  environment  and  whether  risk  has  been  reduced  or  can  be  reduced  to  an 
acceptable  level  for  inclusion  in  an  EMD  program.  Before  the  assessment  process  begins, 
the  SME  team  must  ensure  a  sufficient  understanding  of  the  requirements,  identified 
capabilities,  system  and  software  architectures,  CONOPS,  and/or  the  concept  of  employ¬ 
ment  to  define  the  relevant  environments.  The  SME  team  must  also  ensure  that  its 
understanding  of  design  details  is  sufficient  to  evaluate  how  the  technologies  will 
function  and  interface. 

2.3. 5.2  Prepare,  Coordinate,  and  Submit  the  TRA  Report 

The  CAE  will  submit  a  draft  TRA  report  to  ASD(R&E)  30  days  prior  to  the  Pre- 
MS  B  DAB  Program  Review.  An  update  will  be  submitted  after  PDR  and  source 
selection  and  before  formal  MS  B  or  other  certification  decision  event.  Generally,  the 
TRA  report  should  consist  of  (1)  a  short  description  of  the  program;  (2)  a  list  of  critical 
technologies  that  pose  a  potential  risk  of  program  execution  success,  with  the  PM’s 
assessment  of  the  maturity  of  those  technologies  as  demonstrated  in  a  relevant 
environment  and  a  description  of  any  risk-mitigation  plans;  (3)  the  SME  team 
membership  and  credentials;  (4)  SME  team  findings,  conclusions,  supporting  evidence, 
and  major  dissenting  opinions;  and  (5)  a  cover  letter  signed  by  the  CAE  approving  the 
report;  forwarding  any  requests  for  waivers  of  the  §2 3 66b  certification  requirement  with 
supporting  rationale,  and  providing  other  technical  infonnation  deemed  pertinent  by  the 
CAE  and  PM.  The  CAE  and  PM  can  provide  any  supplemental  material  as  desired. 

The  TRA  report  should  present  the  evidence  and  rationale  for  the  final  assess¬ 
ment.  Evidence  could  include  records  of  tests  or  applications  of  the  technology,  technical 
papers,  reports,  presentations,  and  so  forth.  It  should  explain  how  the  material  was  used 
or  interpreted  to  make  the  assessment.  The  report  should  reference  the  sources  and  the 
pages  in  these  sources  for  the  evidence  presented  in  the  report  to  detennine  whether  a 
technology  has  been  demonstrated  in  a  relevant  environment.  The  material  should  explain 
the  function  of  each  technology  at  the  component,  subsystem,  and  system  levels.  The 
report  should  also  contain  an  explicit  description  of  the  program  increments  or  spirals 
covered  if  appropriate  and  relevant  to  the  Milestone  decision. 

2.3.5.3  ASD(R&E)  Review  and  Evaluation 

ASD(R&E)  will  evaluate  the  TRA  in  consultation  with  the  CAE  and  the  PM. 
ASD(R&E)  will  provide  the  MDA  an  independent  assessment  of  technology  maturity 
based  on  this  process. 
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ASD(R&E)  will  prepare  a  memorandum  that  contains  the  evaluation  results  of  the 
TRA.  The  memo  will  summarize  ASD(R&E)’s  determination  as  to  whether  the 
technologies  of  the  program  have  been  demonstrated  in  a  relevant  environment;  if  not, 
whether  or  not  a  waiver  is  acceptable;  and  a  recommendation  on  the  adequacy  of  risk- 
mitigation  plans  and  the  readiness  of  the  program  to  proceed  to  the  next  stage  of  the 
acquisition  process. 

The  memorandum  is  sent  to  the  MDA,  with  copies  to  the  Overarching  Integrated 
Product  Team  (OIPT),  the  CAE,  and  the  PM. 

2.4  Submitting  a  TRA 

2.4.1  Skeletal  Template  for  a  TRA 

The  TRA  report  should  consist  of  (1)  a  short  description  of  the  program;  (2)  a  list 
of  critical  technologies  that  pose  a  potential  risk  of  program  execution  success,  with  the 
PM’s  assessment  of  the  maturity  of  those  technologies  as  demonstrated  in  a  relevant 
environment  and  a  description  of  any  risk-mitigation  plans;  (3)  the  SME  team 
membership  and  credentials;  (4)  SME  team  findings,  conclusions,  supporting  evidence, 
and  major  dissenting  opinions;  and  (5)  a  cover  letter  signed  by  the  CAE  approving  the 
report;  forwarding  any  requests  for  waivers  of  the  §2 3 66b  certification  requirement  with 
supporting  rationale,  and  providing  other  technical  infonnation  deemed  pertinent  by  the 
CAE  and  PM.  The  CAE  and  PM  can  provide  any  supplemental  material  as  desired. 

The  following  outline  is  a  skeletal  template  for  TRA  submissions: 

1.0  Purpose  of  This  Document 
2.0  Executive  Summary 
3.0  Program  Overview 

3.1  Program  Objective 

3.2  Program  Description 

3.3  System  Description 

4.0  Program  Technology  Risks  Summary  and  Readiness  Assessment 

4.1  Process  Description 

4.2  Identification  of  Technologies  Assessed 

4.3  PM’s  and  SME  Team’s  Assessments  of  Technology  Risk  and 
Technology  Demonstration  in  a  Relevant  Environment 

4.3.1  First  Technology 
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4.3.2  Next  Technology 


5.0  Summary 
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2.4.2  Annotated  Template  for  a  TRA  (Recommended  or  Nominal  Length  of 
Section) 

The  following  outline  is  an  annotated  version  of  the  TRA  template. 

1.0  Purpose  of  This  Document  (One  Paragraph) 

Provides  a  short  introduction  that  includes  the  program  name,  the  system 
name  if  different  from  the  program  name,  and  the  Milestone  or  other  decision 
point  for  which  the  TRA  was  performed.  For  example,  “This  document  presents 
an  independent  TRA  for  the  UH-60M  helicopter  program  in  support  of  the  MS  B 
decision.  The  TRA  was  perfonned  at  the  direction  of  the  UH-60M  Program 
Manager.” 

2.0  Executive  Summary  (One  Page) 

3.0  Program  Overview 

3.1  Program  Objective  (One  Paragraph) 

States  what  the  program  is  trying  to  achieve  (e.g.,  new  capability,  improved 
capability,  lower  procurement  cost,  reduced  maintenance  or  manning,  and  so 
forth).  For  MS  B,  refers  to  the  Capability  Development  Document  (CDD)  that 
details  the  program  objectives. 

3.2  Program  Description  (One  Page  or  Less) 

Briefly  describes  the  program  or  program  approach — not  the  system.  Does 
the  program  provide  a  new  system  or  a  modification  to  an  existing  operational 
system?  Is  it  an  evolutionary  acquisition  program?  If  so,  what  capabilities  will  be 
realized  by  increment?  When  is  the  Initial  Operational  Capability  (IOC)?  Does  it 
have  multiple  competing  prime  contractors?  Into  what  architecture  does  it  fit? 
Does  its  success  depend  on  the  success  of  other  acquisition  programs? 

Also,  explicitly  identifies  the  program  increments  or  spirals  covered  by  the 
TRA,  if  relevant. 

3.3  System  Description  (Nominally  5  Pages) 

Describes  the  overall  system,  the  major  subsystems,  and  components  to  give 
an  understanding  of  what  is  being  developed  and  to  show  what  is  new,  unique,  or 
special  about  them.  This  information  should  include  the  systems,  components, 
and  technologies  to  be  assessed.  Describes  how  the  system  works  (if  this  is  not 
obvious). 
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4.0  Program  Technology  Risks  Summary  and  Readiness  Assessment 

4.1  Process  Description  (Nominally  2  Pages) 

Tells  the  composition  of  the  SME  team  and  what  organizations  or 
individuals  were  included.  Identifies  the  special  expertise  of  these  participating 
organizations  or  individuals.  This  infonnation  should  establish  the  subject  matter 
expertise  and  the  independence  of  the  SME  team.  Members  should  be  experts  in 
relevant  fields.  Usually,  the  PM  will  provide  most  of  the  data  and  other 
information  that  form  the  basis  of  a  TRA. 

Tells  how  technologies  to  be  assessed  were  identified  (i.e.,  the  process  and 
criteria  used  and  who  identified  them).  States  what  analyses  and  investigations 
were  perfonned  when  making  the  assessment. 

4.2  Identification  of  Technologies  Assessed  (as  Needed) 

Lists  the  technologies  included  in  the  TRA  and  why  they  were  selected  as 
critical.  Describes  the  relevant  environment  in  which  each  technology  was 
assessed.  Normally,  this  would  be  the  operational  environment  in  which  the 
system  is  intended  to  perform;  however,  this  can  be  adjusted  if  the  technology’s 
environment  will  be  controlled  while  it  operates  in  the  system  in  question. 
Includes  a  table  that  lists  the  technology  name  and  includes  a  few  words  that 
describe  the  technology,  its  function,  and  the  environment  in  which  it  will 
operate.  The  names  of  these  technologies  should  be  used  consistently  throughout 
the  document. 

Includes  any  technologies  that  the  SME  team  considers  critical  and  that 
have  not  been  included  in  previously  fielded  systems  that  will  operate  in  similar 
environments. 

Note  that  the  technologies  of  interest  here  are  not  routine  engineering  or 
integration  risk  elements.  They  are  items  that  require  more  than  the  nonnal 
engineering  development  that  would  occur  in  design  for  production  as  opposed  to 
technology  maturation  programs. 

4.3  PM’s  and  SME  Team’s  Assessments  of  Technology  Risk  and 
Technology  Demonstration  in  a  Relevant  Environment  (as 
Needed) 

4.3.1  First  Technology 

Describes  the  technology.  Describes  the  function  it  performs  and,  if  needed, 
how  it  relates  to  other  parts  of  the  system.  Provides  a  synopsis  of  development 
history  and  status.  If  necessary,  this  synopsis  can  include  facts  about  related  uses 
of  the  same  or  similar  technology,  numbers  of  hours  breadboards  were  tested, 
numbers  of  prototypes  built  and  tested,  relevance  of  the  test  conditions,  and 
results  achieved. 
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Describes  the  environment  in  which  the  technology  has  been  demonstrated. 
Provides  a  brief  analysis  of  the  similarities  between  the  demonstrated 
environment  and  the  intended  operational  environment. 

States  whether  the  assessed  technology  has  been  demonstrated  in  a  relevant 
environment  or  not. 

Provides  data,  including  references  to  papers,  presentations,  data  tables,  and 
facts  that  support  the  assessments  as  needed.  These  references/tables/graphs  can 
be  included  as  an  appendix. 

Provides  a  summary  of  planned  risk-mitigation  activities  showing  how  those 
activities  will  reduce  the  risk  of  the  technology  to  acceptable  levels. 

Provides  the  SME  team’s  concurrence  or  non-concurrence  and  the  rationale 
therefore,  and  the  SME  team’s  assessment  of  the  adequacy  of  proposed  risk 
mitigation  plans. 


4.3.2  Next  Technology 

For  the  other  technologies  assessed,  this  paragraph  and  the  following 
paragraphs  (e.g.,  4.3.3,  4.3.4,  and  so  forth)  present  the  same  type  of  infonnation 
that  was  presented  in  paragraph  4.3.1. 

5.0  Summary  (One  Page) 

Includes  a  table  that  lists  the  technologies  that  were  assessed,  the  degree  of 
risk  associated  with  each,  recommended  mitigation  measures  if  any,  and  whether 
each  was  demonstrated  in  a  relevant  environment.  Summarizes  any  technologies 
for  which  the  PM  and  the  SME  team  are  in  disagreement  as  to  the  degree  of  risk 
or  whether  the  technology  has  been  demonstrated  in  a  relevant  environment. 
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2.5  TRL  Definitions,  Descriptions,  and  Supporting  Information 


TRL 

Definition 

Description 

Supporting  Information 

1 

Basic  principles 
observed  and 
reported. 

Lowest  level  of  technology 
readiness.  Scientific 
research  begins  to  be 
translated  into  applied 
research  and  development 
(R&D).  Examples  might 
include  paper  studies  of  a 
technology’s  basic 
properties. 

Published  research  that  identifies  the 
principles  that  underlie  this  technology. 
References  to  who,  where,  when. 

2 

Technology  con¬ 
cept  and/or  appli¬ 
cation  formulated. 

Invention  begins.  Once 
basic  principles  are 
observed,  practical  applica¬ 
tions  can  be  invented.  Appli¬ 
cations  are  speculative,  and 
there  may  be  no  proof  or 
detailed  analysis  to  support 
the  assumptions.  Examples 
are  limited  to  analytic 
studies. 

Publications  or  other  references  that  out¬ 
line  the  application  being  considered  and 
that  provide  analysis  to  support  the 
concept. 

3 

Analytical  and 
experimental  criti¬ 
cal  function  and/or 
characteristic  proof 
of  concept. 

Active  R&D  is  initiated.  This 
includes  analytical  studies 
and  laboratory  studies  to 
physically  validate  the 
analytical  predictions  of 
separate  elements  of  the 
technology.  Examples 
include  components  that  are 
not  yet  integrated  or 
representative. 

Results  of  laboratory  tests  performed  to 
measure  parameters  of  interest  and  com¬ 
parison  to  analytical  predictions  for  critical 
subsystems.  References  to  who,  where, 
and  when  these  tests  and  comparisons 
were  performed. 

4 

Component  and/or 
breadboard  valida¬ 
tion  in  a  laboratory 
environment. 

Basic  technological  compo¬ 
nents  are  integrated  to 
establish  that  they  will  work 
together.  This  is  relatively 
“low  fidelity”  compared  with 
the  eventual  system.  Exam¬ 
ples  include  integration  of 
“ad  hoc”  hardware  in  the 
laboratory. 

System  concepts  that  have  been  consi¬ 
dered  and  results  from  testing  laboratory- 
scale  breadboard(s).  References  to  who 
did  this  work  and  when.  Provide  an  esti¬ 
mate  of  how  breadboard  hardware  and 
test  results  differ  from  the  expected  sys¬ 
tem  goals. 

5 

Component  and/or 
breadboard  valida¬ 
tion  in  a  relevant 
environment. 

Fidelity  of  breadboard 
technology  increases 
significantly.  The  basic 
technological  components 
are  integrated  with 
reasonably  realistic 
supporting  elements  so  they 
can  be  tested  in  a  simulated 
environment.  Examples 
include  “high-fidelity” 
laboratory  integration  of 
components. 

Results  from  testing  laboratory 
breadboard  system  are  integrated  with 
other  supporting  elements  in  a  simulated 
operational  environment.  How  does  the 
“relevant  environment”  differ  from  the 
expected  operational  environment?  How 
do  the  test  results  compare  with 
expectations?  What  problems,  if  any, 
were  encountered?  Was  the  breadboard 
system  refined  to  more  nearly  match  the 
expected  system  goals? 

6 

System/subsystem 
model  or  prototype 
demonstration  in  a 
relevant 
environment. 

Representative  model  or 
prototype  system,  which  is 
well  beyond  that  of  TRL  5,  is 
tested  in  a  relevant  environ¬ 
ment.  Represents  a  major 
step  up  in  a  technology’s 
demonstrated  readiness. 
Examples  include  testing  a 
prototype  in  a  high-fidelity 

Results  from  laboratory  testing  of  a  proto¬ 
type  system  that  is  near  the  desired  con¬ 
figuration  in  terms  of  performance,  weight, 
and  volume.  How  did  the  test  environment 
differ  from  the  operational  environment? 
Who  performed  the  tests?  How  did  the 
test  compare  with  expectations?  What 
problems,  if  any,  were  encountered? 

What  are/were  the  plans,  options,  or 

2-13 


TRL  Definitions,  Descriptions,  and  Supporting  Information  (Continued) 


TRL 

Definition 

Description 

Supporting  Information 

laboratory  environment  or  in 
a  simulated  operational 
environment. 

actions  to  resolve  problems  before 
moving  to  the  next  level? 

7 

System  prototype 
demonstration  in 
an  operational 
environment. 

Prototype  near  or  at  planned 
operational  system.  Repre¬ 
sents  a  major  step  up  from 
TRL  6  by  requiring  demon¬ 
stration  of  an  actual  system 
prototype  in  an  operational 
environment  (e.g.,  in  an  air¬ 
craft,  in  a  vehicle,  or  in 
space). 

Results  from  testing  a  prototype  system  in 
an  operational  environment.  Who  per¬ 
formed  the  tests?  How  did  the  test  com¬ 
pare  with  expectations?  What  problems, 
if  any,  were  encountered?  What  are/were 
the  plans,  options,  or  actions  to  resolve 
problems  before  moving  to  the  next  level? 

8 

Actual  system 
completed  and 
qualified  through 
test  and 
demonstration. 

Technology  has  been 
proven  to  work  in  its  final 
form  and  under  expected 
conditions.  In  almost  all 
cases,  this  TRL  represents 
the  end  of  true  system 
development.  Examples 
include  developmental  test 
and  evaluation  (DT&E)  of 
the  system  in  its  intended 
weapon  system  to  deter¬ 
mine  if  it  meets  design 
specifications. 

Results  of  testing  the  system  in  its  final 
configuration  under  the  expected  range  of 
environmental  conditions  in  which  it  will 
be  expected  to  operate.  Assessment  of 
whether  it  will  meet  its  operational 
requirements.  What  problems,  if  any, 
were  encountered?  What  are/were  the 
plans,  options,  or  actions  to  resolve 
problems  before  finalizing  the  design? 

9 

Actual  system 
proven  through 
successful  mission 
operations. 

Actual  application  of  the 
technology  in  its  final  form 
and  under  mission  condi¬ 
tions,  such  as  those 
encountered  in  operational 
test  and  evaluation  (OT&E). 
Examples  include  using  the 
system  under  operational 
mission  conditions. 

OT&E  reports. 
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List  of  Acronyms 


ACAT 

Acquisition  Category 

AS 

Acquisition  Strategy 

ASD(R&E) 

Assistant  Secretary  of  Defense  for  Research  and 
Engineering 

ADM 

Acquisition  Decision  Memorandum 

CAE 

Component  Acquisition  Executive 

CDD 

Capabilities  Development  Document 

CONOPS 

Concept  of  Operations 

DAE 

Defense  Acquisition  Executive 

DAB 

Defense  Acquisition  Board 

DoDI 

Department  of  Defense  Instruction 

DSAB 

Defense  Space  Acquisition  Board 

DT&E 

Developmental  Test  and  Evaluation 

EMD 

Engineering  and  Manufacturing  Development 

IMP 

Integrated  Master  Plan 

IMS 

Integrated  Master  Schedule 

IOC 

Initial  Operational  Capability 

MDA 

Milestone  Decision  Authority 

MDAP 

Major  Defense  Acquisition  Program 

MAIS 

Major  Automated  Infonnation  System 

MS 

Milestone 

MSA 

Material  Solution  Analysis 

OIPT 

Overarching  Integrated  Product  Team 

OT&E 

Operational  Test  and  Evaluation 

PEO 

Program  Executive  Officer 

PDR 

Preliminary  Design  Review 

PM 

Program  Manager 

R&D 

Research  and  Development 

RFP 

Request  for  Proposal 

S&T 

Science  and  Technology 

SME 

Subject  Matter  Expert 

TDS 

Technology  Development  Strategy 

ACR-1 


TRA 

TRL 

U.S.C. 

USD(AT&L) 

WBS 

WSARA 


Technology  Readiness  Assessment 
Technology  Readiness  Level 
United  States  Code 

Under  Secretary  of  Defense  for  Acquisition,  Technology, 
and  Logistics 

Work  Breakdown  Structure 

Weapons  Systems  Acquisition  Reform  Act 


ACR-2 


